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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE 1: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Eureka Project 147 was established in 1987, with funding from the European Commission, to develop a system for 
the broadcasting of audio and data to fixed, portable or mobile receivers. Their work resulted in the publication of 
European Standard, EN 300 401 [1], for DAB (see note 2) which now has worldwide acceptance. The members of the 
Eureka Project 147 are drawn from broadcasting organizations and telecommunication providers together with 
companies from the professional and consumer electronics industry. 

NOTE 2: DAB is a registered trademark owned by one of the Eureka Project 147 partners. 
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1 Scope 

The present document describes the protocol required to create the DAB user appHcation "MOT Slide Show". 

The "MOT Slide Show" user appHcation applies the DAB-MOT protocol (EN 301 234 [3]) and allows a service 
provider to deliver a sequence of slides which carry information in form of images. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI EN 300 401: "Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile, 

portable and fixed receivers". 

[2] ETSI TS 101 756: "Digital Audio Broadcasting (DAB); Registered Tables". 

[3] ETSI EN 301 234: "Digital Audio Broadcasting (DAB); Multimedia Object Transfer (MOT) 

protocol". 

[4] ETSI TS 101 498-1: "Digital Audio Broadcasting (DAB); Broadcast website; Part 1: User 

application specification". 

[5] ISO/lEC IS 15948: "Information technology - Computer graphics and image processing - Portable 

Network Graphics (PNG): Functional specification". 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CD Compact Disc 

DAB Digital Audio Broadcasting 

FIC Fast Information Channel 

FIDC Fast Information Data Channel 

JPEG Joint Pictures Expert Group 

MOT Multimedia Object Transfer 

MSC Main Service Channel 

PAD Programme Associated Data 

PNG Portable Network Graphics 

UA User Application 

UTC Universal Time Coordinated 
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Introduction 



The user application Slide Show provides the user with a sequence of slides which carry information in the form of 
images. The slides will be presented on an appropriate display. 

The main use for this user application will be in the context of a programme service component. Examples are: 

news programme items complemented by photos from the reported events; 



• 



• programme items with popular songs accompanied by photos of the favourite groups or the covers of the CD 
the songs are taken from. 

The user application may also be provided as a data service component and may show e.g. the panorama, to be seen 
from different mountains, so as to inform hikers and skiers about the different local conditions and to support them in 
deciding where to pursue their sporting activity best. 

The slides may carry not only photos or graphics, but also text. However, the Slide Show user application is optimized 
for conveying photos and graphics, rather than text. So text has to be rendered and sent as a PNG or JPEG image. If the 
application provider wishes to convey text adapted and optimized to the DAB transmission chain and to the resources at 
the receiving terminal, he is advised to make use of either the user application "Dynamic Label" or the user application 
"Broadcast Web Site" (TS 101 498-1 [4]). 

Once activated the Slide Show is a service provider driven user application, which does not require any interaction from 
the user of the corresponding service component. Each slide appears automatically on the display and will be replaced 
under the control of the service provider according to the needs of his service. 

The user application Slide Show can be realized in the following ways: 

• in the PAD of an audio service component of a programme or a data service; 

• as a secondary data service component of a programme or a data service (in this case the Slide Show will be a 
packet mode service component); 

• as the primary service component of a data service (in this case the Slide Show will be a packet mode service 
component). 

The first implementation of Slide Show terminals relied on the parameter TriggerTime. Its presence was used to 
indicate to the terminals that a Slide Show user application was available and that this object was at least part of that 
Slide Show. A further restriction was that they understood only TriggerTimes of "NOW". In order to recognize a new 
slide a changed ContentName or a changed VersionNumber (or both) was required by these first implementations. The 
present document no longer applies to these early Pilot Project receivers. Readers should refer to the earlier 
version (VI. 1.1) of the present document for more details. 



5 Operation of the IVIOT slide show user application 

The Slide Show user application simply conveys one slide at a time from the user application provider to the slide show 
terminal. After complete and error-free reception it is presented on the display as triggered by the user application 
provider and replaces the previous slide. 

The exact details on the timing issues are given in clause 5.4. 



5.1 Transport 



The Slide Show user application applies the MOT protocol: Each slide, together with its parameters, is taken as one 
MOT object: it is segmented and its segments are transferred according to the rules of the MOT protocol. MOT headers 
and bodies are used. Because only one object is transferred at a time, MOT directories are not used. 

A Slide Show may be transferred either in the PAD part of a MSC stream audio sub-channel or in a MSC packet mode 
data sub-channel. 
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Wireless broadcast channels like DAB may be disturbed and so bit errors may corrupt the objects. Therefore the objects 
should be repeated sufficiently, applying one of the repetition methods offered by the MOT protocol and/or the DAB 
system itself. 

The slides will experience different delays (according to different reception conditions in different places), until the 
complete object is available in an error-free state to all the terminals within the intended coverage area. If the user 
application provider wants to ensure a precise start of the slide presentation, he has to start the transmission sufficiently 
in advance and to set the TriggerTime parameter to a value in the future (and not equivalent to NOW, see clause 5.3). 

5.2 Storage and memory management 

The user application requires the receiving terminal conceptually to control four buffers; one buffer for re-assembly of 
the currently received segments of the incoming slide, one buffer for holding the slide for rendering (JPEG decoding for 
example), the third one for storing the image in a presentable format (i.e. bitmap) and the fourth buffer for holding the 
slide currently being presented on the display. 

Figure 5.1 describes the path from re-assembly to presentation. 




NOTE: When the TriggerTime is reached a slide would be copied from the rendering buffer to the screen buffer. 
Figure 5.1 : Buffer management model for a MOT Slide Show decoder 



5.3 



Presentation 



The Slide Show user application works with one display only: it can present one slide at a time. 

Before an object can be presented as a slide, its content has to be handled by the source decoder, e.g. in case of a JPEG 
picture it has to be processed by the JPEG decoder. The content decoding requires processing time which may delay the 
presentation, in addition to the transmission delay. 

The presentation time of the new slide can be controlled by the user application provider, as will be explained below. 
However, there is no explicit way of removing a slide from the display. It can only be replaced by a new one. It is the 
task of the user application provider to ensure that the slides presented are always up-to-date and that especially at the 
junction between different programme items no obsolete information is left on the display. This, for example, can 
simply be realized by transmitting and displaying the station logo or an "empty" slide. 

If a slide is completely rendered and a new slide is received before the old slide is triggered, then the old slide shall be 
discarded and the new slide shall be processed. 

The provider can control the presentation start of a slide by using one of three options: 

• TriggerTime: Now 

The slide is presented immediately after complete, error-free reception and content decoding (rendering). The 
presentation will vary at different terminals, because they will work under different reception conditions and 
with different processing speed. As a result, the start of the presentation may differ by several seconds or even 
tens of seconds. 
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• TriggerTime: UTC 

The desired precise TriggerTime is given in Universal Time Co-ordinated (UTC) and is sent (as part of the 
Header) together with the slide (Body) within the same object. This mechanism requires the provision of FIG 
0/10 in the FIC, which contains the exact UTC (not the Local Time!) as a reference value. Under normal 
operation conditions, all terminals will have the slide available before its signalled presentation start 
(TriggerTime). The presentation (copying the slide to the screen buffer) is triggered as scheduled and therefore 
independent from the variations of the reception conditions and the processing speed. This option, however, 
requires that the user application provider fixes the presentation time in advance, i.e. before the transmission of 
the object is started. This may be difficult, when the presentation has to be synchronized precisely to a 
programme service component, i.e. it has to be synchronized to the first beats of a music title, because in some 
operational environments this information is not available sufficiently in advance or because in live 
transmission the start of the new item is decided immediately before start by an operator, without look ahead 
time. This difficulty can be avoided, if the third option is applied. 

• Header update 

The slide is transmitted as an object without any information about the TriggerTime, but sufficiently in 
advance, so that all terminals will have received and rendered the object. As soon as the user application 
provider has decided on the TriggerTime, a Header update object containing the TriggerTime (as UTC or as 
value "now") is transmitted. This Header update object will experience no significant transmission delay, 
because it is of relatively small size. 

The user application may be terminated by updating the FIG 0/13 signalling. DAB data terminals will usually react on 
the termination of an application by making another application automatically available for the user i.e. another 
secondary data service component or another application in PAD. 



5.4 Timing issues 



The model of a MOT Slide Show decoder shown in figure 5.1 implies that while a slide is being rendered, its holding 
buffer must not be overwritten with the next slide (or Header update). If the processing power of the MOT Slide Show 
decoder is too low to process every slide, it shall not copy objects into the holding buffer before the rendering of the 
slide already contained in the holding buffer is completed. This means that a slow MOT Slide Show decoder will 
discard some slides, but display as many as possible. 

The user application provider should try to give the MOT Slide Show decoder as much time as possible to render a slide 
before the next object is broadcast. 

The lifetime of a slide inside the MOT Slide Show decoder is as follows: 

TT(n) RT(n) WT (n) FT (n) 

\ \ \ \ \ ^ 

TO(n) Tl{n) T2 (n) T3 (n) T4 (n) 

TT(n): Transmission Time period for object n. It starts with the first segment received from the object and ends when 
the object is completely re-assembled and copied into the holding buffer. 

RT(n): Rendering Time period for object n. It starts when a slide is copied into the holding buffer and ends when it is 
rendered into the rendering buffer. Note that in the diagram below, RT(n) is shown as RT without a time index, as it is 
assumed for simplicity to be a constant for all objects. 

WT(n): Waiting Time period for object n. It starts when the slide is rendered and ends when it is copied to the screen 
buffer. The time when it is copied is determined by the TriggerTime parameter (either delivered together with the slide 
within the same object or transmitted as a separate header update after the slide object). 

PT(n): Presentation Time period for object n. It starts when the slide is copied to the screen buffer and ends when the 
next slide replaces this slide or the Slide Show is terminated (signalled in the FIC). 

The provider knows the time instant TO(n) (start of transmission of object n), Tl(n) (end of transmission of object n), 
T3(n) in the case that a TriggerTime not equivalent to NOW is signalled (start of presentation of object n) and T4(n) 
(end of presentation of object n, either identical with T3(n + 1) or with the dropped signalling of the user application in 
the FIC). 



£75/ 



9 ETSI TS 101 499 V2.1.1 (2006-01) 

The user application provider needs to allow sufficient time between slide changes to ensure that all receivers have a 
reasonable chance of capturing, rendering and displaying the slide. Figure 5.2 illustrates the times involved and allows 
such estimates to be made. In this example, each slide object consists of several segments, any of which may fail to be 
received (as marked by "X") on a particular transmission. 
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Figure 5.2: Buffer usage and timing example 

NOTE: An object should only be triggered once there has been sufficient time for the decoder to receive all the 
segments of the object and render it. This trigger may occur during the transmission of a subsequent 
object (as shown by Trigger n in figure 5.2) or in the gap between objects (see Trigger n+1). 

It is important that providers allow sufficient time between transmitting an object and triggering it for the slowest of 
terminals and the worst reception conditions. If TriggerTime NOW is signalled, the provider should estimate the 
rendering time and use the estimated point of time T2(n ) to determine when the holding buffer is available. A provider 
may assume that the slowest receiver can render any object up to the maximum allowed complexity within five seconds. 
The service provider should also control the timing of objects to prevent any object being displayed for a period of less 
than a few seconds. If this is not done, the visual effect may be undesirable. 

The user application provider must ensure that the buffers required for the reception of the slide show are available 
when needed. This requires at least the following: 

• For the assembly buffer, T0(n+1) must be later than Tl(n). This means that a new object should not be started 
before the previous one is fully transmitted. If a terminal starts to receive a new object while still waiting to 
complete an earlier one, the earlier object should be deleted and never presented. 

• For the holding and rendering buffers, Tl(n+1) must be later than T3(n). This means that a new object must 
not be completed until the previous object has been triggered and is being displayed. Because the provider 
cannot predict when an object will be completed (this depends on the channel error rate), the provider must 
ensure that at least one segment of object n+1 is held back until T3(n). 

As an example, consider an image of 10 kbytes. With the overhead of the MOT transport, this may equate to 12 kbytes. 
Over an 8 kbit/s channel, this would require 12 seconds per transmission. Allowing the original plus two extra 
repetitions to counteract errors gives a time TT(n) of 36 seconds. The rendering delay will depend on the size of the 
object, its complexity and the technology employed in the receiver. However, the delay is guaranteed to be less than 
five seconds, so in this example, the delay from the start of transmission, TO(n) to the trigger time, T3(n) should be at 
least 41 seconds. 
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Conclusion 



The transmission of an object (slide or Header update) should not be finished before the previous slide has been 
displayed. In other words: the end of the previous slide's transmission plus its estimated rendering time plus possibly a 
waiting time (resulting from a TriggerTime not equivalent to NOW) should have expired beforehand. 



Interface to the Transport layer MOT 



Slide Shows are implemented in the DAB system by transferring the slides including all necessary control information, 
as objects according to the Multimedia Object Transfer protocol MOT used with the two Transport Mechanisms 
"MSC stream audio" (PAD part) and "MSC packet mode data" (Transport Mechanisms "MSC stream data" or "FIDC" 
are not supported). 

MOT headers and bodies are used (MOT Directory shall not to be used). 

6.1 MOT ContentTypes and ContentSubTypes 

According to the MOT protocol, each object has to be characterized by its ContentType and ContentSubType 
(see EN 301 234 [3] and TS 101 756 [2]). The user application requires this information in order to address the 
corresponding content decoders correctly. The following types are the only ones permitted for the use in the Slide 
Show user application. 

6.1 .1 ContentType "Image" 

6.1 .1 .1 ContentSubType "JFIF" (JPEG) 

For an image/ jpeg content all receivers must conform to the following restrictions: 

• a receiver must support baseline coding as a minimum; 

• a receiver need not support progressive and/or multiscan coding; 

• a receiver need not support arithmetic entropy coding; 

• a receiver must support JPEG files with up to 4 components (colour channels) at a resolution of up to 
8 bits/component. 

A receiver shall ignore any images it is unable to decode. 

6.1 .1 .2 ContentSubType "PNG" 

The image /png content type shall be deemed to indicate content conforming to version 1.1 of the PNG specification 
(ISO/IEC IS 15948 [5]). The receiver need not support extension "chunks" outside this PNG specification. 

A receiver shall ignore any images it is unable to decode. 

6.1.2 ContentType "MOT transport" 
6.1 .2.1 ContentSubType "Header update" 

In addition to the objects carrying the slides themselves, special objects with ContentType "MOT transport" and 
ContentSubType "Header update" can be used to transmit the TriggerTime for the presentation of the slide that was 
broadcast most recently. It is sent only if that shde object has been broadcast or is being broadcast without its own 
TriggerTime parameter. 
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6.2 MOT Parameters for the slide objects 

Only the MOT parameters listed in the table below may be used with the SlideShow application. All other parameters 
shall be ignored by the receiver. 



Parameter 


Parameter Id 


Specified in 


IVIandatory for UA Provider 


IVIandatory 
for Receiver 


Occurrence 


ContentName 


OxOC 


MOT 

EN 301 234 [3] 


Yes 


Yes 


Single 


TriggerTime 


0x05 


The present 
document 


No (if not present, the object must 
be triggered by a "Header update" 
(see clause 6.3) or it will never be 
presented) 


Yes 


Single 



6.2.1 ContentName 

According to the MOT protocol the ContentName is needed for identifying and handling the object in the memory 
management. Therefore its use is mandatory within the Slide Show user application. The ContentName must be 
changed with each slide to prevent problems with object management throughout the processing chain and particularly 
with the Header update mechanism. This is because the header update is used to trigger a slide with a matching 
ContentName. If two objects have the same content name, there is a risk that a header update will trigger the wrong 
slide. This could happen if the signal is interrupted and an old slide is still waiting to be triggered when a header update 
is received. 

ContentNames may be re-used after a sufficient interval such that it is very unlikely for a receiver to be confused by a 
new object and a previous one with the same name. Because the slideshow does not cache objects, this need only be a 
fairly short interval. For example, objects may be named SlideOOl, Slide002 ... Slide999, SlideOOl, etc. If the header 
update trigger mechanism is not used, then names may of course be recycled sooner. 

6.2.2 TriggerTime 

This parameter specifies the time at which the presentation takes place. The TriggerTime activates the object according 
to its ContentType. The value of the parameter field is coded in the UTC format (see EN 301 234 [3], clause 6.2.4.1). 

If an object should be presented as soon as it is rendered, a TriggerTime of "NOW" is used. This is indicated by setting 
the TriggerTime validity flag to 0. 

The service provider controls the presentation of the slide by setting this MOT parameter. If a slide object is broadcast 
without any TriggerTime parameter, it can only be presented by the terminal if this slide object is directly followed by a 
"Header update" object with the TriggerTime for that slide. 

The parameter TriggerTime is permitted only once, i.e. if this object is to be presented later on once again, it has to be 
broadcast once again completely. It is not sufficient to send only the new TriggerTime (by a Header update or by 
sending a new header for that slide object), because the slide show terminal is not expected to store the object after this 
object has been replaced by the presentation of a new slide. 

The TriggerTime parameter can take the value NOW or a value coded in UTC. If the TriggerTime is coded in UTC, the 
Slide Show terminal has to assure that the presentation of the slide can start at the given time instant. 

6.3 MOT parameters for tine Header update 

The "Header update" object carries the parameters listed in the table below. All other parameters shall be ignored by the 
receiver. 



Parameter 


Parameter Id 


Specified in 


Mandatory for UA Provider 


Mandatory 
for Receiver 


Occurrence 


ContentName 


OxOC 


MOT 

EN 301 234 [3] 


Yes 


Yes 


Single 


TriggerTime 


0x05 


present 
document 


Yes 


Yes 


Single 
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6.3.1 ContentName 

This parameter is used to link the Header update to the sHde object, the TriggerTime of which is to be updated. 

The ContentName must refer to the sHde that was sent directly before the "Header update". It is not possible to send 
multiple slides in advance and trigger any one of those. If the "Header update" does not refer to the slide in the 
holding/rendering buffer then both the "Header update" and the slide shall be removed from their respective buffer in 
the receiver. 

6.3.2 TriggerTime 

This parameter carries the update information, i.e. the TriggerTime parameter of the slide object. The TriggerTime 
parameter may carry either the value NOW or a value coded as UTC. There is only one value for the TriggerTime 
parameter allowed, i.e. the parameter may occur in the Header update object only once. 



6.4 Optional MOT features 



Because User Application SlideShow is intended to be a simple application, the following optional MOT features are 
not supported: 

• Caching: since caching is only supported in MOT directory mode, it is not appropriate for this application. 

• Conditional Access on MOT level: scrambling on MOT level is limited to MOT directory mode. However, 
scrambling on subchannel or on datagroup level is permitted for the User Application SlideShow. 

• Compression on transport level (MOT level): images in JPEG and PNG formats are already compressed, so 
further compression on transport level would not be advantageous. 



7 Application signalling 



The use of the SlideShow application within a DAB ensemble shall be signalled by the use of FIG 0/13. The 
UserApplicationType value is given in TS 101 756 [2]. There is only one profile supported, so no user application data 
bytes shall be conveyed in this FIG. The receiver shall discard all user application data bytes. 



8 Other requirements 

8.1 Display restrictions 

Receivers must be able to display an image at a resolution of 320 x 240 pixels at a colour/grey scale depth of 8 bits per 
pixel (1/4 VGA). If a receiver cannot display an image at this resolution, it is permitted to rescale it, provided the aspect 
ratio is maintained, and the image is fully visible. 

If a slide is broadcast which is smaller than 320 x 240 pixels, then it shall be displayed in the centre of the screen 
surrounded by a black background if needed. 

Content providers need to be aware that if they broadcast an image larger than 320 x 240 pixels, it may be cropped by 
the receiver. However, receivers are only permitted to crop at the right hand side and at the bottom of the image. 

Receivers should display images using a 4:3 aspect ratio, so that the pixel spacing is the same in the horizontal and 
vertical directions. Content providers may assume that an object drawn using equal pixel spacing will be displayed with 
geometric properties matching the original within the same limits as are typical for domestic television. 
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8.2 Object size restrictions 



The maximum file size of a slide (JPEG or PNG) should not exceed 50 kbytes. All receivers shall be able to decode 
images up to this maximum size. Receivers must ignore images whose sizes exceed their capabilities. Therefore, 
although a content provider may provide an image file of size exceeding 50 kbytes, such a file may not be displayed by 
all receivers. 
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